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Abstract 

This work is devoted to constraint solving motivated by the de- 
bugging of constraint logic programs a la GNU-Prolog. The paper 
focuses only on the constraints. In this framework, constraint solv- 
ing amounts to domain reduction. A computation is formalized by a 
chaotic iteration. The computed result is described as a closure. This 
model is well suited to the design of debugging notions and tools, for 
example failure explanations or error diagnosis. In this paper we detail 
an application of the model to an explanation of a value withdrawal in 
a domain. Some other works have already shown the interest of such 
a notion of explanation not only for failure analysis. 



1 Introduction 

Constraint Logic Programming (CLP) JE2] can be viewed as the reunion of 
two programming paradigms : logic programming and constraint program- 
ming. Declarative debugging of constraints logic programs has been treated 
in previous works || and tools have been produced for this aim ]16| dur- 
ing the DiSCiPl (Debugging Systems for Constraint Programming) ESPRIT 
Project. But these works deal with the clausal aspects of CLP. This paper 
focuses on the constraint level alone. The tools used at this level strongly 
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depend on the constraint domain and the way to solve constraints. Here 
we are interested in a wide field of applications of constraint programming: 
finite domains and propagation. 

The aim of constraint programming is to solve Constraint Satisfaction 
Problems (CSP) ||17|| , that is to provide an instantiation of the variables 
which is correct with respect to the constraints. 

The solver goes towards the solutions combining two different methods. 
The first one (labeling) consists in partitioning the domains until to obtain 
singletons and, testing them. The second one (domain reduction) reduces 
the domains eliminating some values which cannot be correct according to 
the constraints. Labeling provides exact solutions whereas domain reduction 
simply approximates them. In general, the labeling alone is very expensive 
and a good combination of the two methods is more efficient. In this paper 
labeling is not really treated. We consider only one branch of the search tree: 
the labeling part is seen as additional constraint to the CSP. In future work, 
we plan to extend our framework in order to fully take into account labeling 
and the whole search tree (instead of a single branch). 

This kind of computation is not easy to debug because CSP are not 



algorithmic programs [|T3 |. The constraints are reinvoked according to the 
domain reductions until a fix-point is reached. But the order of invocation 
is not known a priori. 

The main contribution of this paper is to formalize the domain reduction 
in order to provide a notion of explanation for the basic event which is "the 
withdrawal of a value from a domain" . This notion of explanation is essential 
for the debugging of CSP programs. Indeed, the disappearance of a value 
from a domain may be a symptom of an error in the program. But the error 
is not always where the value has disappeared and an analysis of the expla- 
nation of the value withdrawal is necessary to locate the error. || provides 
a tool to find symptoms, this paper provides a tool which could be used to 
find errors from symptoms. Explanations are a tool to help debugging: we 
extract from a (wide) computation a structured part (the explanation) which 
will be analyzed more efficiently 

We are inspired by a constraint programming language over finite do- 
mains, GNU-Prolog M , because its glass-box approach allows a good under- 
standing of the links between the constraints and the rules. 

To be easily understandable, the notion of explanation will be first defined 
in a framework which includes arc consistency and next in a more general 
framework which includes hyper-arc consistency and also some weaker con- 
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sistencies usually used in the implemented constraint solvers. 

An explanation is a subset of rules used during the computation and 
which are responsible for the removal of a value from a domain. Several 
works shown that detailed analysis of explanations have a lot of applications 



10| , [TTH . In dynamic problems, the explanations allow to retract constraints 
without beginning the computation again. In backtracking algorithms, the 
explanations avoid to repeatedly perform the same search work. This intelli- 
gent backtracking can be applied to scheduling problems. It has been proved 
efficient for Open-shop applications. They are useful for over-constrained 
problems too. Explanations provide a set of constraints which can be re- 
laxed in order to obtain a solution. But these applications of explanations 



are outside the scope of this paper (see [fLip . Here, our definitions of ex- 



planations are motivated by applications to debugging, in particular to error 
diagnosis. 

An aspect of the debugging of constraint programs is to understand why 
we have a failure (i.e. we do not obtain any solution) 0. This case appears 
when a domain becomes empty, that is no value of the domain belongs to a 
solution. So, an explanation of why these values have disappeared provides 
an explanation of the failure. 

Another aspect is error diagnosis. Let us assume an expected semantics 
for the CSP. Consider we are waiting for a solution containing a certain value 
for a variable, but this value does not appear in the final domain. An expla- 
nation of the value withdrawal help us to find what is wrong in our program. 
It is important to note that the error is not always the constraint respon- 
sible of the value withdrawal. Another constraint may have made a wrong 
reduction of another domain which has finally produced the withdrawal of 
the value. The explanation is a structured object in which this information 
may be founded. 

The paper is organized as follows. Section |2| gives some notations and 
basic definitions for Constraint Satisfaction Problems. Section ^| describes a 
model for domain reduction. Section |] applies the model to explanations. 
Next section is a conclusion. 



2 Preliminaries 

We use the following notations: If F — (Fi) ieI is a family indexed by /, and 
J C /, we denote by F\j the family (Fj)j £j indexed by J. If F = (Fi) ieI 
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is a family of sets indexed by /, we denote by Yl F t ne product Y\ i£l F% = 
{(ei)i e j | for each i G I, e< G Fj}. 

Notations in terms of families and tuples as in [[L7j] are convenient nota- 
tions in our framework. They are more readable than notations in terms of 
cartesian products as in H for example. 

Here we only consider the framework of domain reduction as in |], 



18| . More general framework is described in JL4|. 

A Constraint Satisfaction Problem (CSP) is made of two parts, the syn- 
tactic part: 

• a finite set of variable symbols (variables in short) V; 

• a finite set of constraint symbols (constraints in short) C; 

• a function var : C — > V(V), which associates with each constraint 
symbol the set of variables of the constraint; 

and the semantic part: 

• a family of non empty domains indexed by the set of variables D = 
(D x ) xeV , each D x is the domain of the variable denoted by x (D x ^ 0); 

• a family of relations (sets of tuples) T = {T c ) c& c indexed by the set of 
constraints C, where for each c G C, T c C Yl D\var(c), the members of 
T c are called the solutions of c. 

A tuple t G n D is a solution of the CSP (V, C, var, D, T) if for each 
c G C, t\ var ^ G T c . 

We introduce some useful notations: V = Y\_ xe yV{D x ) (the search space) 
^V{W) = Y[ X&W V{D X ). 

For a given CSP, one is interested in the computation of the solutions. 
The simplest method consists in generating all the tuples from the initial do- 
mains, then testing them. This generate and test method is clearly expensive 
for wide domains. So, one prefers to reduce the domains first ("test" and 
generate). 

Here, we focus on the reduction stage. The computing domains must 
contain all the solutions and must be as small as possible. So, these domains 
are "approximations" of the set of solutions. We describe now, a model for 
the computation of such approximations. 
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3 A Model of the Operational Semantics 

We consider a fixed CSP (V, C, var, D, T). 

We propose here a model of the operational semantics of the computation 
of approximations which will be well suited to define explanations of basic 
events useful for debugging. Moreover main classical results || [14J are proved 
again in this model. 

The goal is to compute an approximation of the solutions. A way to 
achieve this goal is to associate with the constraints some reduction rules. 
A rule works on a subset of the variables of the CSP. It eliminates from 
one domain (and only one in our framework based on hyper-arc consistency) 
some values which are inconsistent with respect to the other domains. 

Definition 1 A reduction rule r of type (W, y), where W C V and y G W, 
is a function r : V(W) — > V(D y ) such that: for each d, d' G T>(W), 

• (monotonicity) {for each x G W , d x C d' x ) r(d) C r(d'); 

• (contractance) r(d) C d y . 

The solver is described by a set of rules associated with the constraints 
of the CSP. We can choose more or less accurate rules for each constraint (in 
general, the more accurate are the rules, the more expensive is the compu- 
tation). 

Other works consider more general kinds of rules [|], [3] , their types have 
the form (W, Z) with Z C W C V. 

Example 1 Hyper-arc consistency 

Let W C V, y G W, T C U D \w and d G V(W). The reduction rule r of 
type (W, y) defined by r(d) = {t y \ t G (Yl d) HT} is an hyper-arc consistency 
rule, r removes inconsistent values with respect to the variable domains. 
When W is {x, y} it is the well known arc consistency framework. 

Example 2 GNU-Prolog 

In GNU-Prolog, such rules are written xinr 0, where r is a range dependent 
on domains of a set of variables. The rule x in . .max(y) of type ({x, y}, x) 
is the function which computes the intersection between the current domain 
of x and the domain {0, 1, . . . , max(y)} where max(y) is the greatest value 
in the domain of y. 
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For the sake of simplicity, for each rule, we define its associated reduction 
operator. This operator applies to the whole family of domains. A single 
domain is modified: the domain reduced by the reduction rule. 

The reduction operator associated with the rule r of type (W, y) is reduc r : 
V — > V defined by: for each d G V, 

• reduc r (d)\ v \ {y} = d\ v \ {y y, 

• reduc r (d) y = r(d\w)- 

Note that reduction operators are monotonic and contractant (but they are 
not necessarily idempotent). 

A reduction rule r is correct if, for each d &V, for each solution t G Yl D, 
t e Y\d ^ t e Yl reduc r (d). 

Lemma 1 A reduction rule r of type (W, y) is correct if and only if, for each 
solution t, r(({t x }) xeW ) = {t y }. 

Proof. =>•: apply the definition with d "reduced" to a solution. 
<=: because reduction operators are monotonic. □ 

In practice, each constraint of the CSP is implemented by a set of reduc- 
tion rules. 

Let c e C. A reduction rule r of type (W, y) with W C var(c) is correct 
with respect to c if, for each d G V, for each t G T c , t G n^l«or(c) =^ t G 
J] reduc r (d)\ var{c) . 

Lemma 2 A reduction rule r of type (W,y) is correct w.r.t. a constraint c 
if and only if, for each t G T c , r(({t x }) xeW ) = {t y }. 

Proof. apply the definition with d = ({t x }) xt =v such that 

\tx)x&var(c) G T c . 

<=: because reduction operators are monotonic. □ 

Note that if a reduction rule r is correct w.r.t. a constraint c of the CSP 
then r is correct. But the converse does not hold. 

Example 3 GNU-Prolog 

The rule r : x in 0. .max(y) is correct with respect to the constraint c 
defined by var(c) = {x, y} and T c = {(x i— > 0, y ^ 0), (x i— > 0, y i— > 1), (x i— > 
l,y i— > 1)} (D x = D y = {0, 1} and c is the constraint x < y). Indeed, 
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• r(x h+ {0}, y i- {0}) = {0} n {0} = {0}; 

• r(x ^ {0}, y ^ {1}) = {0} n {0, 1} = {0}; 

• r(x^{l},2/^{l}) = {l}n{0,l} = {l}. 

Let R be a set of reduction rules. 

Intuitively, the solver applies the rules one by one replacing the domains 
of the variables with those it computes. The computation stops when one 
domain becomes empty (in this case, there is no solution), or when the rules 
cannot reduce domains anymore (a common fix-point is reached). 

We will show that if no reduction rule is "forgotten", the resulting do- 
mains are the same whatever the order the rules are used. 

The computation starts from D and tries to reduce as much as possible 
the domain of each variable using the reduction rules. 

The downward closure of D by the set of reduction rules R is the greatest 
common fix-point of the reduction operators associated with the reduction 
rules of R. 

The downward closure is the most accurate family of domains which can 
be computed using a set of correct rules. Obviously, each solution belongs 
to this family. 

Now, for each x G V, the inclusion over V(D X ) is assumed to be a well- 
founded ordering (i.e. each D x is finite). 

There exists at least two ways to compute the downward closure of D by 
a set of reduction rules R: 

1. the first one is to iterate the operator T> — ► D defined by d i— > (f] reR reduc r {d) x ) x& v 
from D until to reach a fix-point; 

2. the second one is the chaotic iteration that we are going to recall. 
The following definition is inspired from Apt || . 

A run is an infinite sequence of operators of R. A run is fair if each r G R 
appears in it infinitely often. Let us define an iteration of a set of rules w.r.t. 
a run. 

Definition 2 The iteration of the set of reduction rules R from the domain 
d G T> with respect to the run r 1; r 2 , . . . is the infinite sequence d°, d l , d 2 , . . . 
defined inductively by: 
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1. d° = d; 

2. for each j G IN, d^ +1 = reduc rj+l (di). 

A chaotic iteration is an iteration w.r.t. a fair run. 

The operator d i— > (f] reR reduc r (d) x ) x( zv may reduce several domains at 
each step. But the computations are more intricate and some can be useless. 
In practice chaotic iterations are preferred, they proceed by elementary steps, 
reducing only one domain at each step. The next result of confluence || 
ensure that any chaotic iteration reaches the closure. Note that, because D 
is a family of finite domains, every iteration from D is stationary. 

Lemma 3 The limit of every chaotic iteration of the reduction rules R from 
D is the downward closure of D by R. 

Proof. Let be the downward closure of D by R. Let d°, d 1 , . . . 
be a chaotic iteration of R from D with respect to r\, r 2 , . . .. Let 
d w be the limit of the chaotic iteration. Let (Ai) ie i jZ (Bi) ie j 
denotes: for each i G /, Ai C Z^. 

For each i, □ d l , by induction: □ d° = D. Assume C d l , 
by monotonicity, reduc ri+1 (Q) = |Z reduc ri+1 (d l ) = d l+1 . 
d u C 9: There exists k G IN such that d w = d k because |Z is 
a well-founded ordering. The run is fair, hence d k is a common 
fix-point of the reduction operators, thus d k |Z (the greatest 
common fix-point). □ 

The fairness of runs is a convenient theoretical notion to state the previous 
lemma. Every chaotic iteration stabilizes, so in practice the computation ends 
when a common fix-point is reached. Moreover, implementations of solvers 
use various strategies in order to determinate the order of invocation of the 
rules. 

In practice, when a domain becomes empty, we know that there is no 
solution, so an optimization consists in stopping the computation before the 
closure is reached. In that case, we say that we have a failure iteration. 
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4 Application to Event Explanations 

Sometimes, when a domain becomes empty or just when a value is removed 



from a domain, the user wants an explanation of this phenomenon |Tl| , g|. 
The case of failure is the particular case where all the values are removed. 
It is the reason why the basic event here will be a value withdrawal. Let us 
consider an iteration, and let us assume that at a step a value is removed from 
the domain of a variable. In general, all the rules used from the beginning of 
the iteration are not necessary to explain the value withdrawal. It is possible 
to explain the value withdrawal by a subset of these rules such that every 
iteration using this subset of rules removes the considered value. This subset 
of rules is an explanation of the value withdrawal. This notion of explanation 
is declarative (does not depend on the computation). We are going to define 
a more precise notion of explanation: this subset will be structured as a tree. 

For the sake of clarity, it will be achieved first in a basic but significant full 
arc consistency like framework. Next, we extend it to weaker arc consisten- 
cies (partial arc consistency), and finally to a framework including hyper-arc 
consistency as a special case. The full and the partial hyper-arc consistency 
of GNU-Prolog are instances of this framework. 

First, we consider special reduction rules called rules of "abstract arc 
consistency" . Such a rule is binary and its type has the form ({x, y},y), that 
is it reduces the domain of y using the domain of x. 

An abstract arc consistency reduction rule r is defined by two variables 
in r and out r and a function arc r : D outr —>■ V(D irLr ). 

Intuitively, out r is the variable whose domain is modified according to the 
domain of the other variable in r , and, for e G D outr , arc r (e) is a superset of 
the values connected to e by the constraint associated with r (see for example 
figure [1]) . 

Formally, the type of r is ({in r , out r }, out r ) and r(d) = {e G d outr \ 
arc r (e) fl d irir ^ 0} for each d G V({in r , out r }). 
So we have the obvious lemma: 

Lemma 4 For each abstract arc consistency reduction rule r and e G D outr , 
and for each d G V({in r , out r }) 

/\ ft d inr ^ e £ r(d) 

f£arc r (e) I 
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Figure 1: The particular case of arc consistency 

In particular, if arc r (e) = then we have e £" r(d). 
Example 4 Arc consistency 

In the framework of arc consistency, each constraint c is binary, that is 
var(c) = {x, y}, and it provides two rules: T\ of type ({x, y},x), rx(d) = 
{e e d x \ 3f e d y ,(x \— > e, y i— ► /) £ T c }, that is, for each e £ D;,., 
arc ri (e) = {/ £ D y | (x i— > e, y \— > /) £ T c }, and the other rule r 2 of 
type ({x, y},y) defined similarly. 

Note that it is possible to define weaker notions of arc consistency, such that 
arc ri (e) D {/ £ D y \ (x i— > e, y i— > f) £ T c }. But, it will be dealt later in a 
more general framework. 



Example 5 GNU-Prolog 

Let us consider the constraint "x #< y" in GNU-Prolog. This constraint is 
implemented by two reduction rules, it is the glass-box paradigm P, p0] : 

1. T\ of type ({x,y},x) (i.e. in ri = y, out n = x), with, for each e £ D x , 
arc ri (e) = {/ £ D y \ e < /}; 

2. r 2 of type ({x, ?/},?/) (i.e. m r2 = x, out r2 = y), with, for each e £ 
arc T2 (e) = {f e D x \ f < e}. 
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Let us suppose that each r G R is such an abstract arc consistency re- 
duction rule. 

Let us consider an iteration d°, d 1 , . . . of R from D with respect to the run 
r 1; r 2 , . . .. Let us assume that the value e has disappeared from the domain 
of the variable out n at the i-th step, that is e G d % ^ r but e G" d l ouU . Note 

that d^ tr . = r i (d i - 1 | {in ^ } ) = {e G | arc ri (e) n d*" 1 ^ 0}. So 

arc ri (e) n d*" 1 = 0, i.e. for each / G arc n (e), f G" d l ~ l . 

According to the previous lemma e G" d^. because l\ f€arCn{e) f & d\~\ 
But if / G" d\~^ it is because there exists jf < i such that / has disappeared 
at the j/-th step that is / G d^ 1 but / G" d£ r (note that in r . = out Tj ). 

Let us define p(e, i) = {(/, j) | / G arc n (e)J G" d J ou ^ , / G }. 

So e ^ d Lt ri because A(/, i ) ep(e , i ) / ^ • 

We are going to define the notion of explanation by abstracting d: 

Definition 3 (compare with the previous lemma) For each reduction rule r, 
for each e G D outr , we define the deduction rule named (e, r): 

(e,r) : (e,out r ) <- {(f,in r ) \ f G arc r (e)} 

(e,out r ) is the head of the rule and {(/, in r ) \ f G arc. r (e)} is its body. 

In particular, when arc r (e) = the body is empty and the deduction rule 
is reduced to "the fact" (e, r) : (e, out(r)) <— 0. 

Intuitively, a deduction rule (e,r) : (e,out(r)) <— {(f,in r ) \ f G arc r (e)} 
should be understood as follow: if all the / G arc r (e) are removed from the 
domain of in r then e is removed from the domain of out(r). 

The set of deduction rules (e, r) where r G R and e G -D ou t r is exactly an 
inductive definition according to [[J, and a proof tree rooted by (e, y) where 
y = out r G V and e & D y will be called an explanation for (e, y). Note that 
a leaf of an explanation corresponds to a fact (e, r) that is the case where 
arc r (e) = 0. 

Intuitively, the proof tree provides an explanation of the reason why e 
may be removed from the domain of y. 

It is important to note that an explanation is merely a tree made of 
deduction rules, i.e. the d % of an iteration are not part of the explanation. 

Example 6 GNU-Prolog 

Let us consider the 3 constraints x #< y, y #< z, z #< x with D x = D y = 
D z = {0, 1, 2}. The reduction rules are: 
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(0,x) 

(1,2/) (2,2/) 
(l,r 3 ) (2,r 3 ) 

(2,r 5 ) 



-(0,ri) 



(0,x) 

:i,y) (2,?/) 

(l,r 2 ) (2,r 3 ) 



-(0,n) 



(0,x) 



-(0,r 6 ) 



(0,x) 



-(0,r 6 ) 



Figure 2: Value Withdrawal Explanations 



• r\ of type ({x, y},x), defined by ri(d) = {e G d x | arc ri (e) D d y ^ 0} 
where arc ri (e) = {/ G D a | e < /}; 

• r 2 of type ({x, y}, y), defined by r 2 (d) = {e G d y \ arc r2 (e) fl d x ^ 0} 
where arc r2 (e) = {/ G D x \ f < e}; 

• r 3 of type ({y,z},y), defined by r 3 (d) = {e G d y | arc r3 (e) n 4 ^ 0} 
where arc r3 (e) = {f E D z \ e < /}; 

• r 4 , r 5 , r 6 are defined in the same way. 

Figure ^| shows three different explanations for (0, x). For example, the first 
explanation says: is removed from the domain of x by the reduction rule 
T\ because 1 is removed from the domain of y and 2 is removed from the 
domain of y. 1 is removed from the domain of y by the reduction rule r 3 
because 2 is removed from the domain of z, and so on... 
The first and third explanations correspond to some iterations (see exam- 
ple 0). But the second one does not correspond to an iteration. This intro- 
duces some questions (which are going to be answered by theorem 0). 

Explanations are very declarative but they can be extracted from itera- 
tions. 

We are going to define an explanation associated with the event "with- 
drawal of a value from a domain in an iteration". It is introduced by the 
following theorem. 
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Theorem 1 (There exists an explanation for (e,y)) if and only if (there 
exists a chaotic iteration with limit such that e G" dy) if and only if (e $l ® y , 
where is the downward closure). 

Proof. The last equivalence is proved by lemma [3]. About the 
first one: 

<=: Let d°, d 1 , ... be the chaotic iteration (with respect to the run 
ri, r 2 , . . .). There exists i such that e G d l ~ l but e G" d y . 
We define a tree expl(e,y,i) which is an explanation for (e,y). 
expl(e,y,i) is inductively defined as follows: 

• y = out n ; 

• the root of the tree expl(e,y,i) is labeled by (e,y); 

• (we have previously observed that e G" d l outr = d y because 

A(/,i)ep( e> i) / £ rf o U i r . and, for each (f,j) G p(e,i), ow£ r . = 
m r J the deduction rule used to connect the root to its chil- 
dren, which are labeled by the (/, out rj ), is (e, ri) : (e, out n ) <— 
{(f,i n n) I / e arc ri (e)}; 

• the immediate subtrees of expl(e, y, i) are the expl(f, in n ,j) 
for (/, j) G p(e,«). 

=^: let us consider a numbering 1, . . . , n of the nodes of the expla- 
nation such that the traversal according to the numbering from 
n to 1 corresponds to a breadth first search algorithm. For each 
i G {1, . . . , n}, let (ej, Ti) be the name of the rule which links the 
node % to its children, and let d°, . . . , d n be the prefix of every 
iteration w.r.t. a run which starts by r±, . . . , r n . By induction we 
show that e, G" d 1 ^,^ so e G" for every iteration whose run 
starts by ri, . . . , r n . □ 

It is important to note that the previous proof is constructive. The defini- 
tion of expl(e,y,i) gives an incremental algorithm to compute explanations. 

Example 7 GNU-Prolog 
(Continuation of example |) 

Let us consider the iteration r§, r%, r\. The first explanation of figure ^ says: 
At the beginning, d° x = {0, 1, 2}. arc r5 (2) = so 2 G" d\. 
Then, d\ = {0,1}. arc r3 (l) = {2} so 2 £ d\ =>- 1 ^ dj. arc r3 (2) = so 
2*d}. * 

Then, dj = {0}. arc n (0) = {1, 2} so (1 £ d£ A 2 £ dj) =^ £ d|. 
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We extend our formalization in order to include weaker arc consistency 
rules. In GNU-Prolog, a full arc consistency rule uses the whole domain of 
the input variable, whereas, a partial arc consistency rule only uses its lower 
and upper bounds. In that case we need two functions arc, one for each 
bound. 

An abstract arc consistency reduction rule r is now defined by two vari- 
ables in r and out r . and a set Arc r of functions D outr — > V{D irir ). 

The type of r is ({in r , out r }, out r ) and r(d) = {e G d outr | AarceArc r ( arc ( e ) n 
din r 7^ 0)} for each d G V({in r , out r }). 

Note that for arc consistency, Arc r contains only one function (it is the 
previous framework). 

Obviously, for each arc G Arc r we have: 



Example 8 GNU-Prolog 

Let us consider the constraint "x #= y+c" in GNU-Prolog where x, y are 
variables and c a constant. This constraint is implemented by two reduc- 
tion rules: r\ of type ({x, y},x) (i.e. in ri = y, out ri = x) and r 2 of type 
({x, y},y). In GNU-Prolog, r 1 is defined by the partial arc consistency rule 
x in min(y)+c . .max(y)+c. 



ri(d) = {e G d x | arc^(e) D d y ^ A arc^(e) fl d y ^ 0} where arc^(e) = 
{/ G D y | / + c < e} and arc^e) = {/ G D y \ e < f + c}. 



r 2 of type ({x, y}, y) is defined in the same way by the rule y in min(x)-c . .max(x) -c. 

Let us suppose that each r G -R is such an abstract arc consistency re- 
duction rule. 

Definition 4 For each reduction rule r, for each e G D outr , for each arc G 
Arc r , we define the deduction rule named (e,r,arc): 



Again the set of deduction rules (e, r, arc) is an inductive definition and 
this defines a generalization of our previous notion of explanation. 

Now we generalize the reduction rules to hyper- arc consistency. 




(e, r, arc) : ( 



e,out r ) <— {(f,in r ) \ f G arc(e)} 
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An abstract hyper-arc consistency reduction rule r is denned by a set of 
variables in r , a variable out r and a set Arc r of functions D outr — > ^dlxeira Ac)- 

The type of r is (m r U{owt r }, out r ) and r(d) = {e G rf OU ( r | /\ arc&ArCr {arc(e)n 
Tlx&nr 4 7^ W for eacn ^ G V(in r U {owt r }). 

Note that for hyper-arc consistency, Arc r contains only one function. 

Obviously, for each arc £ Arc r we have: 




Intuitively, the t : arc(e) — > m r are choice functions and each t(f) is one x 
such that / x $l d x . 

So we have, for each t : arc(e) — > m r , 

( A /*(/) * ) =► e * r ( rf ) ( 3 ) 

\ /Garc(e) / 



Example 9 Hyper-arc Consistency in GNU-Prolog 

Let us consider the constraint "x #=# y+z" in GNU-Prolog. Let D x = D y = 
D z = {1,2,3}. The constraint is implemented by three reduction rules: 

• n of type ({x,y,z},x) defined by n (d) = {e £ d x \ 3f £ Yl ve{y z} d v ,e = 
f y + /,}; 

• r 2 of type ({x, y, z}, y) and r 3 of type ({x, y, z}, z) defined in the same 
way. 
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Here, in ri = {y,z}, out ri = x and Arc ri = {arc}, where arc(e) = {/ G 
FLe^,*} D v \ e = f y + f z }. 

For example, arc(3) = {(y i— > 1, z i— > 2), (y i— > 2, z i— > 1)}. We have as an 
instance of (1): (1 g dy V 2 g d g ) A (2 g dyV 1 g d x ) 3 g n(d). But 
(1 £ 4 V 2 £ 4) A (2 £ d y V 1 £ 4) is equivalent to (1 £ d y A 2 £ 4) V (1 £ 
^ 9 A 1 ^ 4) V (2 ^ 4 A 2 ^ d 9 ) V (2 ^ 4 A 1 ^ d 2 ) This equivalence is the 
corresponding instance of (2). So we have the following instances of (3): 

• lgdyA2gdy=>3g n(d); 

• 1 G" 4 A 1 G' 4 ^ 3 G>i(d); 

• 2 g" 4 A2 gdy =^3 £ n(d); 

• 2 ^ 4 M ^ 4 ^ 3 ^ n(d). 

Again a more general notion of explanation is defined by abstracting d. 
Let us suppose that each r G -R is such an abstract hyper-arc consistency 
reduction rule. 

Definition 5 For eac/i reduction rule r, for each e G D outr , for each arc G 
Arc r , for each t : arc(e) — >■ m r , we define the deduction rule named (e, r, arc, £) 

(e,r,arc,t) : (e,out r ) <- {(/*(/), *(/)) | / G arc(e)} 

The inductive definition for hyper-arc consistency is larger than for arc 
consistency because of the number of variables of the rules, but in practice 
(GNU-Prolog), the rules contain two or three variables. 

5 Conclusion 

This paper has given a model for the operational semantics of CSP solvers 
by domain reduction. 

This model is applied to the definition of a notion of explanation. An 
explanation is a set of rules structured as a tree. An interesting aspect of our 
definition is that a subtree of an explanation is also an explanation (inductive 
definition). 

This model can be applied to usual constraint solvers using propagation, 
for example it takes into account the full and the partial hyper-arc consistency 
of GNU-Prolog. 
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As it is written in the introduction, constraint solving combines domain 
reduction and labeling. A perspective is to really take into account labeling 
in our model. 

We plan to use explanations in order to diagnose errors in a CSP (accord- 
ing to an expected semantics) , in the style of [7j . 

Another perspective is to take advantage of the glass-box model |J and 
more generally the S-box model || and to distinguish different levels of rules 
(x in r, built-in constraints, S-box, ...) 
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